home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0329.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  2.9 KB  |  73 lines
  1.  
  2. > Date: Tue, 10 Nov 92 19:23:12 CST
  3. > From: Dan Connolly <connolly@pixel.convex.com>
  4. > 
  5.  
  6. > I keep running across interesting bits of evidence that tell me that
  7. > indexes should be a type of link rather than a type of document.
  8. > 
  9.  
  10. > <dd><a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>
  11. > <a HREF="wais://quake.think.com/directory-of-servers.src">describe</a>
  12. > 
  13.  
  14.  
  15. Dan,
  16.  
  17. If you found that most index documents are empty, then that was probably
  18. because you were in gopherspace -- in waisspace they all have descriptions.
  19.  
  20. [[even though as Ed points out the description lives in one place and the index  
  21. in another so it is dificult to know which address to use! On that point,
  22. ed, I chose to refer to the index as that is what actually MUST be available,
  23. when the source file is not essential, it is just icing on the cake]].
  24.  
  25. How about above instead of
  26.  
  27. > <dd><a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>
  28.  
  29. using
  30.  
  31. > <dd><a HREF="wais://quake.think.com/INFO" RELATIONSHIP=SEARCHME>search</a>
  32.  
  33. This expresses that the type of relationship between the documents is
  34. that when you follow the link you should search the seocnd index. 
  35.  
  36.  
  37. An important addition is just a document-wide
  38. <LINK HREF="wais://quake.think.com/INFO" RELATIONSHIP=SEARCHME>
  39. empty element which makes a document searchable, directing seraches
  40. to a given index. Similarly  RELATIONSHIP=GLOSSARY would
  41. allow double-clicked words to be looked up in a remote glossary.
  42.  
  43. This would solve the problem with WAIS source files, in that their hypertext
  44. representation would have such a link to the index, so the source file itself
  45. appears searchable. There are lots of places where this would be neat.
  46.  
  47. We have been over this a little before.  Perhaps we should allow either
  48. option, as it is so checken-and-egg as a problem.
  49.  
  50. The argument for the W3 model is that often the user will want to search
  51. or not search a single index, and he doesn't want two operations: one to
  52. select the fact that he wants to search (click) and one to search
  53. (typetypetyepe return).  He just wants one.   After all,
  54. if he clicks on a gopher index link, what does he get? a serach panel.
  55. And what is the difference between that and a serachable document?
  56. Only speed of display. If the serachable document can come up as fast as
  57. a search panel, then there is no contest. If not, there is.
  58.  
  59. In the long term the search will become (if my philosophising of
  60. the oher day comes true) an instance of a class of search query, for which
  61. an editor will exist if the client supports it. So searches with
  62. toggle buttons and radio buttons and stuff will be possible,
  63. and a gopher serach and W3 search will be subclasses.
  64.  
  65. I feel that we are talking about optimising speed when the net is slow
  66. here. In general, I don't want to talk about a dictionary (search[1].
  67. describe[2]) I want to talk about a dictionary[3]. The former seems kinda
  68. messy. It just saves time given a slow network now...
  69.  
  70. Tim
  71.  
  72.  
  73.